The IP Multimedia Subsystem (IMS) is an architectural framework for delivering Internet Protocol (IP) multimedia services. It constitutes an approach to providing internet based multimedia services, including voice calls and messaging, to various wireless telecommunications networks, such as Global System for Mobile Communications (GSM), wireless LAN, and Universal Mobile Telecommunications System (UMTS), as well as fixed line networks. One of the protocols used in the IMS network is the Session Initiation Protocol (SIP). A terminal attached to the IMS network is referred to as User Equipment (UE).
SIP messages in the IMS are processed using a collection of servers or proxies, collectively known as Call Session Control Function (CSCF).
FIG. 1 shows some of the basic components of an IMS network. A CSCF 10 is provided in a session layer (also known as the IMS layer or signalling plane) of the architectural framework. A central node of this session layer is a Serving-CSCF (S-CSCF) 12. The S-CSCF 12 performs session control, and interfaces with a Home Subscriber Server (HSS) 14 located in a service/application layer. The S-CSCF 12 may interface with the HSS 14 for, amongst other things, downloading user profiles or subscription information, or performing authentication procedures. The S-CSCF 12 is also responsible for handling SIP registrations, which allows it to bind a user's location (for example an IP address of a UE 20) and the SIP address. The S-CSCF 12 also decides to which application server(s) 16 a SIP message will be routed, in order to provide their respective services. The application servers 16 in the application layer provide services that have some relevance to the communication session established in the session layer. These include applications that can enhance communication capabilities in some way, for example advanced conferencing facilities of a call session being controlled by the session layer.
The CSCF 10 also comprises a Proxy-CSCF (P-CSCF) 18, which is the first point of contact for a UE 20. As will be appreciated by a person skilled in the art, the transport layer provides basic IP connectivity between physical items of equipment (i.e. UEs and P-CSCF or P-CSCF and S-CSCF), including connectivity to the outside world such as the public Internet.
A P-CSCF 18 is discovered by a UE 20 prior to registration, and does not change for the duration of the registration. The P-CSCF 18 contacts the S-CSCF 12 to authenticate a UE 20, and other nodes trust the P-CSCF 18 such that they do not have to authenticate the user again. The P-CSCF 18 may also include a Policy Decision Function (PDF), which is used for operations such as policy control and bandwidth management. The PDF can also be a separate function provided elsewhere in the framework.
The CSCF 10 also comprises an Interrogating-CSCF (I-CSCF) 22. The domain name and IP address of the I-CSCF 22 are published in a Domain Name System (DNS), so that remote servers can find the I-CSCF 22, and use the I-CSCF 22 as a forwarding point (for example during registration) for SIP messages to this domain. The I-CSCF 22 queries the HSS 14 using what is known as the Diameter Cx interface, for example to retrieve user location, and routes SIP requests to their respective assigned S-CSCFs.
Nowadays, many enterprises and other organisations require their own telecommunications capabilities to support their own internal communications as well as supporting communications with the outside world. This avoids incurring unnecessary charges and provides added value in terms of services and features available, integration with other enterprise applications, and so forth. These capabilities are provided through enterprise telecommunication networks (also known as corporate telecommunication networks, CN, or simply enterprise networks).
Release 8 of the 3rd Generation Partnership Project (3GPP), Technical Specification 24.229 provides support for so-called Next Generation Corporate Networks 24 (NGCN), also known as Private Branch Exchange (PBX) or enterprise networks. An NGCN is a self-contained corporate network designed to take advantage of emerging IP-based communications solutions, and can have their own applications and service provisioning.
At present the following methods exist by which an NGCN 24 can be connected to the 3GPP IMS network:                the NGCN 24 can act as a regular UE 20;        the NGCN 24 can act as a UE 20 with additional privileges, the so called “privileged sender”        
The latter method provides the NGCN 24 with more power, since the NGCN 24 is allowed to originate call sessions with originating identity not restricted to the registered identities.
A P-CSCF 18 has responsibility for controlling if the NGCN 24 can act either as a regular UE or a “privileged sender”.
The authorization policy must somehow be made available to the P-CSCF 18. The following options are possible ways of making the authorization policy available to the P-CSCF 18:                1. the authorization policy can be provided using a parameter in a P-Associated-Uniform Resource Identifier (P-Associated URI) header of a “2xx SIP response” response message to a “SIP REGISTER” request message, or the “2xx SIP response” to a “SIP SUBSCRIBE” request message (see further details below);        2. the authorization policy can be provided in a body of the “SIP REGISTER” response message (see further details below);        3. the authorization policy can be provided in the “SIP NOTIFY” message of the registration event package (see detailed description below); or        4. the P-CSCF can download the authorization policy, etc.        
Each of the options mentioned above for providing the authorization policy from the home network to the P-CSCF 18 has its respective disadvantages.
The first option has the disadvantage that the parameter in the P-Associated-URI header of the signalling message “2xx SIP response” could become quite large as more policies become available in the future. Furthermore, if there are several P-Associated-URI headers with large parameters, the size of the SIP response to the SIP REGISTER request may become quite large, and if the SIP REGISTER request is sent using a User Datagram Protocol (UDP), the SIP response to the SIP REGISTER could become IP fragmented, since RFC3261 requires the same transport protocol for SIP response as used for the SIP request.
The second option also has similar problems to the first, i.e. the problem of IP fragmentation of the SIP responses.
The third option ensures that no SIP response IP fragmentation occurs. However, there is a time delay between reception of the SIP 2xx response to the SIP REGISTER request in the P-CSCF 18 and the reception of the SIP NOTIFY request with the authorization policy, as will be described in greater detail below.
The fourth option does not state what triggers a P-CSCF to download the policy, or where the P-CSCF would download the policy from. As such, the P-CSCF would have to try and download the policy on a consistent basis, which would result in too much unnecessary signalling.
FIG. 2, shows the basic steps in a registration flow by a NGCN 24, according to the third option described above.
The NGCN 24 begins a registration procedure by sending a SIP REGISTER request message 201 to a P-CSCF 18. Upon receipt of the SIP REGISTER request message 201, the P-CSCF 18 forwards the SIP REGISTER request towards the S-CSCF 12, shown as message 202. It will be appreciated by a person skilled in the art that, in practice, the forwarding of the SIP REGISTER request towards the S-CSCF 12 may involve the P-CSCF 18 forwarding the SIP REGISTER request towards an I-CSCF (not shown), which queries an HSS to check if the user is defined, in which case the I-CSCF selects the S-CSCF to which the SIP REGISTER request message is forwarded. In response to receiving the SIP REGISTER request message 202, the S-CSCF 12 responds by sending a SIP 2xx response message 203 to the P-CSCF 18.
Upon receipt by the P-CSCF 18 of the SIP response message 203, the P-CSCF 18 forwards the SIP response message 203 to the NGCN 24, shown as message 204, thereby indicating to the NGCN 24 that registration has been successful. The P-CSCF 18 shall also subscribe to a registered event package, shown as “SIP SUBSCRIBE request for registration event package” message 205.
When the P-CSCF 18 subscribes for the registration event package it expects to receive the following messages in response to the S-CSCF 12 accepting the subscription:                (a) a SIP 2xx response to SIP SUBSCRIBE request message 207, and        (b) a SIP NOTIFY request message 208.        
Upon receipt of a SIP NOTIFY request message 208 the P-CSCF 18 will reply to the S-CSCF 12 with a “SIP 2xx response to SIP NOTIFY request”, message 209.
As mentioned above, if the authorization policy for the NGCN 24 is provided in the SIP NOTIFY request message 208 then, until such time as the P-CSCF 18 receives the authorization policy, the P-CSCF 18 is unable to ensure correct authorization of any SIP requests received from an NGCN 24 (i.e. after the NGCN 24 has received the message 204). As such, there exists a period “t” from when an NGCN 24 receives a SIP 2xx response to SIP REGISTER request message 204, to when the P-CSCF 18 is able to accept further SIP requests from the NGCN 24.
In order to ensure correct policy enforcement, the P-CSCF 18 may:                (a) delay sending of the SIP 2xx response to the SIP REGISTER request message 204 towards the registered NGCN 24, or (b)        (b) reject any request received from the registered NGCN 24 requiring privileges until the SIP NOTIFY request message 208 with authorization is received.        
These delays and rejected requests are disadvantageous, particularly for normal UEs and NGCNs 24 that do not have special privileges.